Content based data routing

ABSTRACT

A method of routing data from a source to one or more clients over a network, where the data conforms to a structured meta-language; in which the routing is performed by a server applying rules to the data itself, and not any address accompanying the data, to determine where to route that data to. The present invention is predicated on the counter-intuitive insight that data does not need to be concealed within a data envelope and given an address label in order to be routed effectively and efficiently. Instead, routing can be performed on the actual content of a message by applying simple routing rules to the data itself by intelligent ‘routing’ servers within the network which can unpack data from their message envelopes and intelligently filter/combine them with data unpacked from other messages to achieve a routing function.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a divisional of U.S. application Ser. No.10/497,125, filed May 28, 2004, which claims the priority of PCTApplication No. PCT/GB02/05577, filed on Dec. 9, 2002, and BritishApplication No. GB 0129381.0, filed on Dec. 7, 2001, the contents ofwhich are hereby incorporated fully herein by reference.

FIELD OF THE INVENTION

This invention relates to data routing. In particular, it relates torouting of data which conforms to a structured meta-language such as theself-describing XML meta-language. The term ‘routing’ refers to anyprocess for directing data from its source to its intended recipient.Messages which implement web services can be routed using thisinvention.

DESCRIPTION OF THE PRIOR ART

Prior art routing of data relies on data being packaged into a dataenvelope, with routing decisions based on an address placed on the dataenvelope; conventionally, the combination of data, plus envelope, plusaddress is called a ‘message’. The approach of ‘address based’ ‘message’routing is used inter alia in:

-   -   (a) direct messaging systems (e.g. e-mail/SMTP; peer-to-peer        Instant Messaging);    -   (b) store and query systems (e.g. relational databases like        Oracle®, which allow clients to send specific queries to a        server and receive a response);    -   (c) publish and subscribe systems (e.g. Usenet, which allows        clients to view/download data and media files from a server);    -   (d) remote execution systems (e.g. RMI for C and Java®, which        allows clients to directly execute specified functions of a        remote application over a network);    -   (e) transaction management middleware systems (e.g. Tuxedo®,        which allows a client to safely execute complex transactions        where a client can request one or more related operations to be        carried out on one or more remote systems and guarantee that        these are only successfully completed if all operations are        valid);    -   (f) message queuing middleware systems (e.g. IBM® MQ Series,        Tibco®, which allow a client to request that a message be sent        to a remote server, and the message queue uses store-and-forward        mechanisms to guarantee delivery even if the server is        unavailable at the time the message was sent);    -   (g) distributed object systems (e.g. CORBA®, DCOM, which allow        for a client to execute methods of a remote object by means of a        proxy class or service accessed through a request broker);    -   (h) filtering systems (e.g. firewalls and email filtering        systems, which allow an administrator to set rules about how        different types of messages should be diverted as they travel        through the system using filtering criteria such as size,        source, destination, security needs, network needs, virus        detection);    -   (i) network level routing systems (e.g. Cisco® internet routers,        which allow clients to send messages as a series of small        packets to a server over a complex network of interconnected        computers such as the internet, using low-level protocol        addressing to identify the destination and ordering of each        package);    -   (j) network level broadcast systems (e.g. m-Bone, that allows a        server to use appropriately configured network servers and        routers to distribute or broadcast message packets to many        clients simultaneously).

But if one is delivering real time messages which can change rapidly(e.g. many times a second) from hundreds or thousands of web services topotentially thousands of users (or more), then this kind of ‘addressbased’ message routing inevitably leads to significant problems. Forexample, where mass message distribution uses a publish/subscribe modelto broadcast continuously updating information, then to ensure thecorrect messages have been received by all clients, the server whichpublishes the information is constrained by the lowest bandwidth of aconnected client, and may have to cache ever increasing (and potentiallyhuge) amounts of data if the network is slow. In many audio and videobroadcast applications, this can be partly solved by ‘dropping’ messagepackets due to network congestions, but this results in a loss ofquality of the resulting sound or image.

With most web-services (as will be described in more detail later inthis section), ad-hoc ‘dropping’ of message packets is unacceptable, sothe only options available today are to reduce the size and quantity ofmessages, or increase the bandwidth of the network. Where directmessaging systems or store/query systems are used, then the volume ofdata traffic can increase roughly as the product of the number of webservices and the number of users; this rate of increase can beunmanageable where you have hundreds of web services, each potentiallyneeding to deliver thousands of updating messages a second to tens ofthousands of users.

In addition to the network strain imposed by address based routing,there is an economic cost to end users: as these end users mayincreasingly pay for data received on a per-bit basis, ‘address based’message routing is potentially very inefficient and costly, particularlyfor large commercial users with many hundreds or thousands of clients,who will otherwise find themselves in effect paying heavily for the samedata to be sent many times over to respond to identical queries.Alternatively, users pay for excess bandwidth to allow for the rare peakconditions they experience at certain points in an application.

A more efficient and effective way of routing data (typically XML data,or a variant of XML) would be a compelling proposition. The presentinvention is such a proposition. It finds particular application inrouting web services related messages. A ‘web-service’ in essenceinvolves the supply of data and/or executable code to a client deviceover the Internet or other network; it is a structured message basedcommunication between two or more computer applications or functions, onthe same or different machines, where the communication happens over apublic, private or local network and where one application/function isproviding a service to another application/function. Web-services mayfor example allow a user to access applications (which wouldconventionally reside on the client device) from a remote provider on apay per use basis over a wide area network such as the Internet. Theterm ‘web-service’ therefore may for example cover the service ofsupplying self-contained, self-describing applications that can bepublished or invoked across the Internet, as well as those applicationsthemselves. Another example could be an application that executes toconvert foreign exchange prices or, more simply, merely supplies up todate stock prices or traffic information. Web-services share the commonfeature that they are delivered using messages. Program developers canaggregate web-services together to form complex, integratedapplications, but doing so requires the data being provided by eachweb-service to be routed efficiently to the correct destinations.

SUMMARY OF THE PRESENT INVENTION

In a first aspect of the present invention, there is a method of routingdata from a source to one or more clients over a network, where the dataconforms to a structured meta-language, the routing being performed by aserver applying one or more rules to the data, and not any addressaccompanying the data, to achieve correct routing of that data,

characterised in that one or more messages are unpacked in order toyield the data and the routing server (a) applies the or each rule tothis unpacked data or one or more sub-sets of this unpacked data andthen (b) constructs one or more messages using some or all of the dataor data sub-set(s).

The present invention is predicated on the counter-intuitive insightthat data does not need to be concealed within an envelope, with theenvelope including an address label, in order to be routed effectivelyand efficiently. Instead, routing can be performed on the actual contentof the data by applying simple routing rules to the data itself by‘routing’ servers within the network. A routing server is any kind ofcomputing device able to apply rules, such as perform queries.

The data against which the rules are applied may form the content (i.e.the information of interest to an ultimate recipient) of and beextracted from a single, whole message, or be a part of a message, or beparts of several messages, or an aggregate of several messages. The dataexiting a routing server does not therefore have to be the same as thedata in any message entering the routing server, unlike prior artrouting approaches, which preserve the integrity of all messages.

The term ‘message’ used in this specification means the combination ofdata (i.e. content of interest to a message recipient) plus dataenvelope; it does not necessarily (although it may) cover conventionalmessages which include address information in a header. Hence, in thepresent invention, the routing may be performed by the server applyingone or more routing rules to the content of interest to a messagerecipient when there is no address accompanying that data. Equally,there may be an address accompanying the data, but that address isignored by the server when applying its routing rules.

Single or multiple messages can be constructed by the routing serverusing the data or data sub-sets from one or several incoming messages.

In a second aspect, there is an apparatus programmed to route data froma source to one or more clients over a network, where the data conformsto a structured meta-language; wherein the apparatus applies one or morerules to the data, and not any address accompanying the data, to achievecorrect routing of that data;

characterised in that the apparatus (a) unpacks one or more messages inorder to yield the data and then (b) applies the or each rule to thisunpacked data or one or more sub-sets of this unpacked data thenconstructs one or more messages using some or all of the data or datasub-set(s).

In a third aspect, there is a message when routed using the method ofrouting as defined above.

Further aspects and details of the invention are specified in theappended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be described with reference to theaccompanying drawings, in which FIGS. 1, 2 and 3 are schematics of theoverall system architecture of a message routing system in accordancewith the present invention.

DETAILED DESCRIPTION OF A PREFERRED IMPLEMENTATION

The present invention will be described with reference to animplementation from Altio Limited of London, UK, called the PresentationServer. The Presentation Server provides the routing functionalitydescribed in the preceding sections. To re-cap on the fundamentals, theprior art approach is for messages to include an address header and foran incoming message to be routed as a unitary block, not to be analysedin any way, other than for its address to be read and used in therouting operation. The present invention challenges this orthodoxy byrequiring that the data content of messages be unpacked and be subjectto rule based filtering in order to achieve routing, with outgoingre-packaged messages comprising data from any combination of the wholeor part of one or more incoming messages (e.g. the sub-set(s) of thedata of one or more incoming messages, the entirety of one or moreincoming messages, the sub-set(s) of some messages and the entirety ofothers, etc.).

The entire approach could be summarised as intelligently‘unpack-filter-repack’ at the routing server. FIG. 1 is a schematicrepresentation of this approach. In FIG. 1, there are several differentkinds of web services 1A to D (1A: news related. 1B: FX pricing andtrading; 1C: hotel reviews. 1D: restaurant reviews). The web servicesrelated data is sent as XML messages 2 to a routing server 3. Therouting server 3 unpacks 4 the XML message data content and then appliesdifferent rules 5A, 5B and 5C to that content. Rule 5A allows throughonly FX related data, routed over a secure link. Rule 5B allows throughnews. Rule 5C allows through data relating to London restaurants andItalian holidays. Content satisfying a rule is then repackaged into XMLmessages 6 and sent to the correct user 7, 8 and 9. In this way, a user7, interested only in seeing data on restaurants in London and Italianholidays is served by rule 5C and hence routed only the data he isinterested in. Similarly, user 8, wanting news headlines, is served byrule 5B. User 9, a FX trader, is served by rule 5A. In this example,user 7 receives data from two different web services message streams 1Cand 1D. Users 8 and 9 however each receive data from a single webservices message stream. More complex combinations are readily achieved.

A further example will illustrate this concept: Suppose that a stockexchange has 1000 different stocks, the prices of which are all changingin real time. The conventional approach to delivering this kind ofinformation would be to host that information on a relational databaseand allow users connected over the interne to post queries to thatdatabase—e.g. “show me your current and historic pricing data onIntel®”. This query is processed by the database and an answer returnedto the user in an envelope with the IP address of the client computerwhich sent the original query. For commercial users, the query would nothowever relate to just a single stock, but to perhaps hundreds andrefresh rates would have to be at short intervals to give accurate data.Multiply this by the tens of thousands of users that mightsimultaneously access a system, and the network traffic and load on thedatabase server can become unmanageable.

With the present invention, rules can be applied by routing servers todrastically diminish the traffic. For example, as illustrated in FIG. 2,an originating server 20 could be supplying real time price data 21 on1000 stocks to a routing server 22. The routing server 22 could applythe single rule to forward on to a client only pricing data of the 30stocks which are currently being displayed by that client. (This wouldrequire the routing server to be aware of what a client was displayingat any instant, but that is possible with systems such as thePresentation Server from Altio Limited of London UK). By applying thissimple rule, the routing server in effect acts as a filter able to routethe correct messages 23, and only the correct messages, to theappropriate clients 24.

Another extension of this principle is that the routing server canreceive continuous real-time message feeds, and manage those feeds suchthat rather than sending all the messages on to a slow client, it canchoose to send only the latest values of the information that haschanged, (e.g. if a stock price changes 5 times since a slow-modemclient received their last price quote for that stock, then the routingserver can choose to send only the latest price and not the other 4).

The routing server can apply many different kinds of rules, such as therules in the following, non-exhaustive list.

-   -   Route messages based on a user's unique identifier—for example        each user's portfolio information is unique to them, so the        ‘routing server’ can support per-user routing in this way.    -   Route messages based on security privileges—using the        appropriate rules, the ‘routing server’ can enforce that        messages are sent only to approved clients (e.g. a bank might        only want to send branch specific information to each branch        rather than sending every branch all the other branch's        information).    -   Routing messages based on rules about client and network        performance—the individual performance of each client, and the        level of congestion of their network could be used to control        the quantity of information sent to the client.    -   Routing based on rules about server performance—if one or more        of the ‘web services’ servers becomes overloaded, the ‘routing        server’ could be used to limit access to the busy server.    -   A legacy system that was designed to support 20 users can be        enhanced to support potentially thousands of users by relying on        the ‘routing server’ to act on it's behalf to manage        interactions with each of those thousands of clients. The        ‘routing server’ rules allow this legacy system to delegate        per-user customisation and security.    -   Rules could be used to divert certain content of an incoming        message over an expensive but highly secure network whilst some        or all of the remaining content is sent through the public        network.    -   Rules could be applied to incoming messages to selectively        encrypt and/or digitally sign portions of a message before        passing it on reducing the CPU cost of the encryption process        without unduly affecting the security of the message.    -   Rules could be applied to incoming messages to selectively        encrypt and/or digitally sign portions of a message with        multiple keys before passing the message on to a broadcast        network that would send the same encrypted message to all        clients, but where each would only be able to decrypt certain        portions of the message.    -   Rules could be applied to hold a certain message until one or        more other messages are received with matching content from the        same or other web service. For example we might wish to group        messages received from both an inventory management system and        an accounting system and only send on a single message based on        the combined pair.

As with the examples above, these rules are inherently not addressbased, but act to filter the business information so that the kind ofreal-time information which ultimately reaches the client conformsexactly to the requirements and access rights of that client. This is amajor evolution over address based routing and offers a fundamentallydifferent approach to message routing to enable the mass publication andinvocation of web-services.

Numerous advantages flow from this new approach:

-   -   Allows real-time web services related message data to be routed        to thousands/tens of thousands of users, yet minimises bandwidth        overhead.    -   Reduces originating server load, e.g. allowing legacy mainframes        designed to service 20 terminals to output data to thousands of        clients (scalability comes from the routing servers placed in        the network).    -   Is readily scalable using parallel routing servers, which can        provide fault tolerance.    -   Facilitates security (powerful encryption rules can be applied        by the routing servers where permissible; where less powerful        encryption is needed in a domain, then the routing servers for        that domain can apply the less powerful encryption rules).    -   Gives users remote from the originating server far more        flexibility in handling/manipulating business information data,        since they can determine their own routing rules, rather than be        subject to business information data which has been centrally        (and inaccurately) mandated. In effect, this yields ‘mass        customisation’ of business information data.    -   Readily facilitates application integration across multiple        information sources.    -   Allows web services providers to genuinely de-couple from what        is happening at the client; instead, they can focus on supplying        their IP, in much the same way as semiconductor IP is supplied        today by ‘fabless’ companies.

Implementations of the present invention may include the followingfeatures:

-   -   Structured meta-language for the data is XML or a variant of        XML.    -   Rules operated by a routing server are continuously updateable.    -   Rules are continuously updateable by messages sent to the        routing server.    -   Rules are applied by the routing server in real time to the        messages.    -   Rules are applied by the routing server in real time to the        messages depending on what needs to be rendered for viewing,        hence restricting updating data to what a user is actually        viewing at any instant, rather than the entire set of things        which the user might be able to look at.    -   Messages from a source are analysed by the routing server and        the routing server applies one or more rules which result in        only a sub-set of that data being routed to a client and a        different sub-set to a different client.    -   Messages from a source are analysed by the routing server and        the routing server applies one or more rules which result in        some or all of that data being combined with messages from a        different source and the combined messages are then routed to a        client; different clients can receive different combinations of        messages.    -   Multiple parallel routing servers can route from a single source        to give scalability.    -   If one routing server from a group of multiple parallel routing        servers fails, then another routing server in that group can        take over.    -   Multiple series connected routing servers can perform routing.    -   If multiple series connected routing servers can route, then a        routing server higher up the hierarchy is insulated from needing        to know the rules which will be applied by routing servers        further down in the hierarchy.    -   Client is a ‘thin’ client; different clients with different        bandwidth connections can all be efficiently provided        information, with clients on lower bandwidth connections not        compromising the data rate for clients with higher bandwidth        connections (unlike publish/subscribe systems). Clients with        less computing power than a desktop PC benefit from the present        approach of shifting the burden of computational analysis needed        to extract the required data from the client end and into the        routing server, which is typically part of the network itself.    -   Rules are structured as queries (e.g. xPath) applied to XML.    -   Messages are Instant Messaging personal communications.

As noted earlier, the present invention finds particular applicationwhen routing data which relates to web services. Web services arecharacterised by one or more of the following:

-   -   A web service is a message based information service accessible        over a public or private network (such as the interne and a        LAN/WAN).    -   A web service can be accessed either by sending a remote request        message and handling the reply message.    -   A web service can also be accessed through a queuing mechanism        that hides the originator and forwards messages on it's behalf.    -   A web service can also be a provider of direct un-queued        messages where the consumer of the web service is fed        information directly from the provider where each is know        explicitly to the other.    -   A web service might be marshalled by an intermediary system who        controls access and resources on the network.    -   A web service might be handled through a transaction management        middleware system that provides guarantees for multi-stage        transactions across one or more web services.

FIG. 3 illustrates a simple rule based approach relating to dealerinformation distribution for one Detroit based car manufacturer. Theobjective of this system to provide up to date data to local car dealersaround the world relating to all car prices, options, special discounts,promotions, local competitor pricing etc. There may be many hundreds ofdealers and each dealer may need to access large amounts of data whichare specific to their local markets. Normally, this would be achievedusing a relational database located in Detroit which serves the globaldealership community. However, we have seen above that this query/answermodel can generate extremely high data traffic volumes; further, alegacy mainframe designed to service perhaps 50 dumb terminals wouldcertainly be unable to cope with the data demands that would be placedon it.

With the Presentation Server implementation illustrated in FIG. 3, theseissues are solved. The Presentation Server (which could be located as asingle server located anywhere in the network, or as multiple connectedservers distributed in the network) allows a single data stream to issuefrom the main relational database 31; this is a set of XML taggedmessages 32 which fully define all data needed to be sent to dealers; itincludes tagged fields which allow efficient rule-based filtering to beapplied. Imagine that the Presentation Server 33 simply has to filterincoming XML message data so that only country and state specific datais sent over the internet to dealers (i.e. US dealers in California areto be continuously pushed real-time data relating only to car pricing,options, competitor pricing etc. relevant to California and not anyother region). It can do this in two simple stages; at a first level 34,it can filter according to country tags embedded in the XML—e.g. allpricing data will have associated with it a country code tag specifyingwhich country it relates to (e.g. US, UK, etc.). The incoming XMLmessages are unpacked; i.e. data of interest to recipients is strippedout of their data envelopes and then queried by the first level routingserver 34 so that US related data (of all categories, including pricing)is filtered to constitute a US specific data stream 35A, UK data isfiltered to constitute a UK specific data stream 35B etc. Then, a secondlevel routing server 36 adds further geographic refinement if needed, asit may be in the US, where there may be state specific promotions etc.The second level router 36 therefore queries for any California etc.specific promotions and other variables. It then constructs (orre-packages) XML based messages 37 specific to all California dealersand outputs these re-packaged messages 38. This is sent over theinternet 39 to a California regional main office 40. This office caninclude its own routing servers, which can apply rules determined atthat office—e.g. the incoming XML messages may include sensitive newmodel release data which the regional main office cannot yet release todealers 41. It can also apply a rule which prevents that data beingaccessible by dealers. Local dealers can access all other data from theDetroit parent directly by accessing the Presentation Server hosted atthe California regional main office. It may chose to integrate this datawith other information useful at a state level (e.g. California news andtraffic alerts).

This overall approach leads to many specific advantages, which have beendefined in general terms above. For example:

-   -   Minimises bandwidth overhead    -   Reduces originating server load    -   Is readily scalable    -   Facilitates security    -   Gives users remote from the originating server far more        flexibility in handling/manipulating business information data    -   Readily facilitates application integration across multiple        information sources

We look next at how querying happens and how it can be used differentlyfrom existing approaches in order to determine how information is routedthrough a network.

In the example above, the rules associated with routing were determinedby somehow associating information tied to a user (or to an enddestination machine) with the information that was being sent across thenetwork. Another example of this would be that stock quotes are held inXML documents and are sent across as new quotes are available. Aseparate XML data set is maintained for the users and the rules and theresponsibilities associated with them. When a new piece of informationis available (such as a new stock quote), that information is sent outfrom the quoting application to the routing server. The routing servercompares information inside the quote against a separate piece ofinformation held in a database locally within the routing server todetermine the destination or the security access for that information.For example, a quote for Amazon.com® would be compared against a list ofusers currently connected to determine which of them wish to receiveand/or should be allowed to receive the information associated with thatquote.

In a news example, news about Amazon.com similarly would be comparedagainst a similar set of rules, except that this case has the additionalconstraint that only premium users get to see the news information. Andso a double check is done by performing a query on the information heldlocally within the routing application to join together the user and thesecurity privilege such that the information is only routed when the twomatch and are successful.

In order to enable data to be delivered correctly, we have determinedthat the routing application in the network performs look-ups or querieson the information held locally within the routing application andcompares it with the data that is being transmitted across the networkin order to determine where the data should be routed.

In order to perform ‘on the fly’ routing of data, it is necessary tohave a mechanism whereby those routing applications themselves are keptup to date on the fly. For relatively static data, such as a list ofusers who are connected within a fairly steady enterprise, it could beconceivable that the routing application simply gets initialized with apredefined set of rules and to look up necessary information to resolvethose rules whilst the machine is running. This is the most basicinstance and would enable an application to perform the sort ofbehaviour described earlier.

If however the information that is to be compared against (or the rulesthat are to be used to determine the distribution of this information)change frequently, or may change during the run lifetime of the productor the application, then it becomes necessary to enable the routingapplication to be updated (i.e. modifications to be stored and processedby the routing server) on the fly, for rules to be added, changed ordeleted, for information associated with those rules, (i.e. the look-uptables or the look-up information), to be maintained in real time andfor the network to be able to distribute amongst itself this informationalso on the fly. This is essential to the correct, fully functionalworking of the routing server.

The next instance of the routing server takes the previous instance astage further and provides for guaranteed or verifiable updating ofinformation, the ability to ensure that the rules to be applied for thesubsequent pieces of information are already in place and will becorrectly applied as soon as the next information is sent.

For example, let us suppose that our user decides to cancel a premiumsubscription. We ought to be able to ensure that future news items sentacross the network are no longer sent to this user. Similarly, if we adda new user to the routing tables we should be able to deliverinformation to a user. As soon as that information is available to therouting application, we should be able to update it on the fly withouthaving to restart the routing applications. Not only should we be ableto verify that the routing transaction and the routing applications havebeen updated correctly before we send the next piece of information, weshould also at the very least have a mechanism to verify that therouters in the network have been updated. This ensures that all theinformation in the network is consistent and follows the correct rules.The intention here is to maintain the entire status of the network withthe rules and the information being consistent at all times.

Once the network becomes the mechanism by which information isaggregated, protected and distributed, it essentially becomes anintelligent processor of information prior to being displayed to an enduser. It is essential that we have mechanisms in place to validate thisstate of the network at any point in time.

In a separate instance, we now deal with the issue of clustered nodes orclustered routers and the way in which they behave.

First, the intention is that all routing applications in the networkshould contain an identical set of rules and look up informationassociated with those rules and should behave individually in a mannerthat will ensure the correct delivery of the information. Whilst thismay introduce some overhead with repeated look-ups occurring as theinformation is successfully transmitted throughout the network, thesimplicity and robustness of this approach is relevant for certainapplications.

The advantage would be that should any one of these routing applicationsfail, any user applications that wish to subscribe to this informationmay simply re-subscribe to an alternative but valid and working routingapplication and therefore, effectively reroute themselves and survivingsignificant attrition within the network application increasingrobustness and stability.

Similarly, by taking a fairly simple approach we are able to build ahighly scalable system without the complexity of determining rules thatdiffer throughout the network.

A further instance of a clustered application would be where the routerssupport different rules and where half of that information and the wayin which it is transmitted to the end user is successively determined asthe information travels the network.

This may be important in cases where the rules that should apply aredetermined not only by a global criteria such as user name andsubscription rate, but might be determined locally in addition to thatby physical location or the device from which the user is connecting. Inother words, it may be valid to send stock quotes to a mobile telephonebut not long news articles. Therefore, in this instance, it might bepossible through the network to configure the information such that, ifyou are connected through a telephone device with a small screen and lowbandwidth, to prevent those messages arriving at the phone orpotentially for a subset of that information to be sent to a phone. Anexample would be whereby the headline of a news article may betransmitted to the phone but the entire content of the article isprevented from being sent.

Similarly, it may be that within an enterprise local area network webuild in rules that allow all information to be transmitted, yet if youare connected from an outside device, that information might berestricted. That way, only users inside an enterprise can access theinformation and from outside the enterprise less of that information isavailable simply due to the security restrictions, or potentially due toother reasons such as limited bandwidth or relevance etc.

Further instances include the following:

-   -   ‘Data Routing’ can be used to intelligently feed a message        broadcast network which would be used to distribute mass content        to many clients, perhaps even over a robust private network        (e.g. we might use an established broadcast mechanism to deliver        the same subset of NASDAQ® stock quotes for just integrated        circuit design companies to all clients).    -   A further instance is where we extend this to allow additional        ad-hoc connections from one or more of the clients to the server        to retrieve unique content to them in addition to the mass        broadcast info (e.g. we might send per-client portfolio        information to each client in addition to the stock quotes sent        above).    -   A further instance is where we maintain a separate full-time        connection to a client to stream/push new/updated information        (eg notification that a sell order for some stock in their        portfolio has been fulfilled). A client could poll to establish        connection with the server on a regular or ad-hoc basis rather        than there being a separate full-time connection tied up for        each client.

1. A method of routing data from multiple sources to multiple clientsover a network, where the data conforms to a structured meta-language,the routing being performed by a routing server applying rule-basedfiltering to the data; including the following steps: (a) unpacking thedata content of multiple incoming messages from their respective messagedata envelopes, with the data content including tagged fields that allowrule based filtering to be applied using those tagged fields; and (b)the routing server performing the rule based filtering using the taggedfields when querying the data content; and (c) the routing server thencombining the data content from multiple incoming messages previouslysent for unpacking into a single outgoing network message and whereinthe unpacked data is analysed by the server and the server applies therule-based filtering which results in some or all of that data beingcombined with data from a different source into one or more messages andthe combined data is then routed to a client.
 2. The method of claim 1in which the structured meta-language is XML.
 3. The method of claim 1in which the rule-based filtering applied by the server is continuouslyupdateable.
 4. The method of claim 3 in which the rule-based filteringis continuously updateable by a message, or a sub-set of a message,being received and processed by the server.
 5. The method of claim 4 inwhich the rule-based filtering is applied by the server in real time tothe data.
 6. The method of claim 5 in which the rule-based filtering isapplied by the server in real time to the data depending on what needsto be rendered for viewing at a client, hence restricting updating datato what a client is actually looking at, rather than the entire set ofthings which the client might be able to look at.
 7. The method of claim1 in which multiple parallel servers can route from a single source togive scalability.
 8. The method of claim 7 in which if one server from agroup of multiple parallel servers fails, then another server in thatgroup can take over.
 9. The method of claim 1 in which multiple seriesconnected servers can perform routing.
 10. The method of claim 9 inwhich a server higher up the hierarchy of a series is insulated fromneeding to know the or each rule which will be applied by a serverfurther down in the hierarchy.
 11. The method of claim 1 in which therule-based filtering is a member selected from the following group ofrules: (a) Route data based on a user's unique identifier; (b) Routedata based on security privileges; (c) Route data based on rules aboutclient and network performance; (d) Route data based on rules aboutperformance, of the server supplying the data, so that if one or more ofthe servers supplying the data becomes overloaded, the routing servercould be used to limit access to the busy server; (e) Route data basedon per-user customisation and security rules delegated by a legacyserver; (f) Route data following rules to divert certain content of anincoming message over an expensive but highly secure network whilst someor all of the remaining content is sent through the public network; (g)Route data by selectively encrypting and/or digitally signing portionsof a message before passing it on, reducing the CPU cost of theencryption process without unduly affecting the security of the message;(h) Route data by selectively encrypting and/or digitally signingportions of a message with multiple keys before passing the message onto a broadcast network that would send the same encrypted message to allclients, but where each would only be able to decrypt certain portionsof the message; (i) Route data by holding a certain message until one ormore other messages are received with matching content.
 12. The methodof claim 2 in which the rule-based filtering is structured as Xqueriescomparing data against data held locally in the server.
 13. The methodof claim 1 in which the data is Instant Messaging personalcommunications.
 14. The method of claim 1 in which the data is webservices related data.
 15. An apparatus comprising a processor andmemory programmed, using program data stored on a computer readablemedium, to route data from multiple sources to multiple clients over anetwork, where the data conforms to a structured meta-language wherein:the apparatus applies rule-based filtering to the data; the apparatusunpacks the data content of multiple, incoming network messages fromtheir respective data envelopes, with the data content including taggedfields that allow rule based filtering to be applied using those taggedfields; and the apparatus performs the rule based filtering using thetagged fields, and constructs a single outgoing network message bycombining data content of multiple incoming messages previously sent forunpacking; and wherein the unpacked data is analysed and then therule-based filtering is applied which results in some or all of thatdata being combined with data from a different source into one or moremessages and the combined data is then routed to a client.
 16. Theapparatus of claim 15 which enables the rule-based filtering to becontinuously updateable.
 17. The apparatus of claim 16 in which therule-based filtering is continuously updateable by a message, or asub-set of a message, which the apparatus stores and processes.
 18. Theapparatus of claim 17 in which the apparatus applies the rule-basedfiltering in real time to the data.
 19. The apparatus of claim 15 inwhich the rule-based filtering is applied in real time to the datadepending on what needs to be rendered for viewing at a client, hencerestricting updating data to what a client is actually looking at,rather than the entire set of things which the client might be able tolook at.
 20. The apparatus of claim 15 when organised into multipleparallel servers which can route from a single source to givescalability.
 21. The apparatus of claim 20 in which if one server from agroup of multiple parallel servers fails, then another server in thatgroup can take over.
 22. The apparatus of claim 15 when organised intomultiple series connected servers to perform routing.
 23. The apparatusof claim 22 in which a server higher up the hierarchy of a series isinsulated from needing to know the or each rule which will be applied bya server further down in the hierarchy.
 24. The apparatus of claim 15 inwhich the rule-based filtering is a member selected from the followinggroup of rules: (a) Route data based on a user's unique identifier; (b)Route data based on security privileges; (c) Route data based on rulesabout client and network performance; (d) Route data based on rulesabout performance, of the server supplying the data, so that if one ormore of the servers supplying the data becomes overloaded, the routingserver could be used to limit access to the busy server; (e) Route databased on per-user customisation and security rules delegated by a legacyserver; (f) Route data following rules to divert certain content of anincoming message over an expensive but highly secure network whilst someor all of the remaining content is sent through the public network; (g)Route data by selectively encrypting and/or digitally signing portionsof a message before passing it on, reducing the CPU cost of theencryption process without unduly affecting the security of the message;(h) Route data by selectively encrypting and/or digitally signingportions of a message with multiple keys before passing the message onto a broadcast network that would send the same encrypted message to allclients, but where each would only be able to decrypt certain portionsof the message; (i) Route data by holding a certain message until one ormore other messages are received with matching content.
 25. Theapparatus of claim 15 in which the rule-based filtering is structured asXqueries comparing data against data held locally in the apparatus.